SECURE INTRANET ACCESS 



FIELD OF THE INVENTION 

5 The present invention relates to computer network security, and more particularly 

to the task of providing a user who is presently at a client machine outside the perimeter of 
a secure network with convenient, efficient, and secure access to data stored on a target 
server which is located within the secure network. 

10 TECHNICAL BACKGROUND OF THE INVENTION 

Distributed computing systems are becoming increasingly useful and prevalent. 
Distributed computers are now connected by local area networks, wide area networks, 
and networks of networks, such as the Internet. Many such networks are secured with a 
security perimeter which is defined by firewall software, routing limitations, encryption, 

15 virtual private networks, and/or other means. Machines within the security perimeter are 
given ready access to data stored in the secure network (possibly subject to user and 
group permissions, access control lists, and the like), while machines outside the perimeter 
are substantially or entirely denied access. 

With the growth of such secure networks and their information content, there is an 

20 urgent need to support secure access by authorized users even when those users log in 
from a client machine outside the network security perimeter. A wide variety of tools and 
techniques relating to networks and/or security are known, at least individually and to at 
least some extent, including: computer network architectures including at least transport 
and session layers, sockets, clients, and servers; hyperlinks and uniform/universal resource 
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locators (URLs); communications links such as Internet connections and LAN 
connections; proxy servers for HTTP and some other protocols; internetworking; 
Kerberos authentication; authentication through certificates exchanged during an SSL 
handshake; tying certificates to access control lists so that users are identified in 
5 certificates presented during the SSL handshake instead of being identified by an IP 

address, DNS name, or username and password; multiple instances of a server on the same 
machine in order to serve both insecure and secure documents; using a single password to 
log into an entire network rather than logging into individual servers; proxy servers as an 
example of servers which require user authentication; a secure sockets layer protocol 
10 manifestation in URLs, including protocol identifiers "http://" and "https://"; the use of a 
specific server port for network communication; various definitions of VPNs (virtual 
private networks); "route filtering" which controls route propagation; Point-to-Point 
Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP); use of encryption 
technologies to provide the segmentation and virtualization required for VPN connectivity 
15 deployed in almost any layer of the protocol stack; transport or application layer VPNs; 
basic VPN requirements such as user authentication, address management, data 
encryption, key management, and multiprotocol support; tunneling by packet 
encapsulation, packet transmission, and packet unencapsulation; Lightweight Directory 
Access Protocol; a split proxy system for a protected computer network; translation 
20 between transport layer protocols; translation between IP and non-IP protocols; a proxy 
server within a network which receives a request for a protected Web resource from a 
browser outside the network and requires authentication of the browser to the.proxy using 
some combination of a user ID and/or password; Novell/NetWare Directory Service 
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(NDS) and user access controls; Windows NT Domain directory; Reverse Proxy/Virtual 
Hosting; a proxy server with HTTP caching; use of a proxy server by configuring client 
software to connect through the proxy server to prevent the client from being connected 
directly to the Internet; SSL encryption; an entry manager which serves as a single point of 
5 network entry for all users; a Trusted Sendmail Proxy, in the context of sensitivity labels 
and privileges, including a small, trusted program which acts as a communication path 
between an inside compartment that performs privileged internal operations and delivers 
local messages and an outside compartment that collects and send messages without 
privilege; a secured https proxy which apparently does SSL tunneling, logging, and 
10 reacting to events; software which apparently allows use of https URLs by way of an SSL 
connection with a program that wraps https calls to http; a protocol stream or content 
processor which knows how to convert something involving an URL into a proprietary 
content container which knows its content and that content's type, for HTTP, HTTPS, 
FTP, gopher, and other protocols; redirection of HTTP requests in connection with an 
15 HTTP proxy; superuser privileges; and object rights and property rights which apply to 
properties of an NDS object, as well as distribution of directory information across the 
network through replication. 

References which mention or discuss these and possibly other tools and techniques 
are identified and discussed relative to the present invention in a Petition for Special 
20 Examining Procedure filed concurrently with the present application. To the extent that 
the Petition describes the technical background of the invention as opposed to the 
invention itself, the text of the Petition is incorporated herein by this reference. This 



3 



incorporation by reference does not imply that the claimed invention was previously 
known. 

Although a wide variety of tools and techniques relating to networks and/or 
security are known, it has not previously been known how to combine them to provide 
5 clients outside a secure network perimeter with sufficiently convenient, efficient, and 
secure access to Web pages stored on servers within the secure network. 

For example, some previous approaches require that the user's name and/or 
password be sent across a network communications link in plain text. Other approaches 
use only a weak form of encryption, such as uuencoding, to protect the authentication 
10 information. In both cases, the authentication information is quite vulnerable to theft and 
misuse. 

As another example, some previous approaches utilized strong encryption but 
required that special software be previously installed on both the client machine which is 
seeking access and on the server machine which holds the data sought by the client. Such 
15 approaches are taken by many virtual private networks, as well as by individual machines 
configured with public key/private key encryption software such as PGP software. These 
approaches protect user authentication information and/or the data which is transmitted 
after a user is authenticated, but they are not sufficiently convenient and efficient. 

In particular, virtual private networks require significant administrative effort and 
20 vigilant attention to details in order to avoid problems arising from incorrect or inconsis- 
tent configurations. Moreover, widely used Web browsers such as those available from 
Netscape and Microsoft do not normally include full support for either virtual private 
networking or application-level encryption software such as PGP software. 
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Accordingly, it would be an advancement in the art to improve the tools and 
techniques that are available to provide a user who is presently at a client outside the 
perimeter of a secure network with convenient, efficient, and secure access to data stored 
on a server located within the secure network. 
5 Such improvements to secure network access are disclosed and claimed herein. 

BRIEF SUMMARY OF THE INVENTION 

In one embodiment, the present invention provides a distributed computing system 
which allows secure external access to a secure network such as a secure intranet. The 
10 system includes a target server within the secure network; a border server within the 

secure network, a client outside the secure network; a user authentication system located 
at least partially within the secure network; and a uniform resource locator transformer. 

The border server is connectable to the target server by a first communications 
link, such as an intranet or Ethernet link. The client is connectable to the border server by 
15 a second communications link, such as a TCP/IP link. The client and the border server are 
configured to support secure sockets layer communication over the second communica- 
tions link using SSL or similar software. 

The secure network is configured with authentication software and supporting data 
to allow direct access to the target server by a user only after the user is authenticated by 
20 the user authentication system. Typically, the user could readily log onto the network from 
an internal client at work, and the security questions addressed by the invention arise 
because the user wishes to log on through an external client at home or in the field rather 
than an internal one at work. 
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The uniform resource locator (URL) transformer modifies non-secure uniform 
resource locators in data being sent from the target server to the client by replacing them 
with corresponding secure URLs to promote continued use of secure sockets layer 
communication. The URL transformer is an "SSL-izer". For instance, the URL 

5 transformer may replace instances of "http" which refer to locations inside the secure 
network 100 by corresponding instances of "https" which refer to the same locations. The 
modifications to the data promote continued use of a secure connection such as an SSL 
connection. An URL transformer may be located on the border server, on the target 
server, or both. If the URL transformer is located on the target server, the system may 

10 include tunneling software for tunneling secure data (which was transformed into secure 
form at the target server) between the client and the target server through the border 
server. 

The border server and/or target server may include one or more data caches. For 
instance, in one configuration the border server has a cache that holds data from the target 

15 server which contains non-secure URLs, and the URL transformer introduces secure 

URLs on the fly without requiring that the transformed data also be cached on the border 
server. In another configuration, a border server cache includes a non-secure data cache 
for internal clients and a secure data cache for external clients. The non-secure data cache 
holds data that contains non-secure URLs, and the secure data cache holds data that does 

20 not contain any non-secure URLs. In yet another configuration, the border server cache is 
simply free of data that contains non-secure URLs. 

In short, systems according to the invention use novel URL transformation and 
more familiar mechanisms such as HTTP redirection and SSL software (in novel ways) to 
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provide secure authentication of a user from an external client and to provide secure 
transmission of confidential data between the target server and the external client. 

By transforming non-secure URLs into secure URLs, the invention forces 
continued use of secure communications despite the inherent security problems caused by 

5 the lack of state information in HTTP. HTTP servers and browsers do not ordinarily 
"remember" security requirements from one Web page transmission to the next without 
some assistance. Accordingly, the present invention forces use of HTTPS or a similar 
secure connection each time the user follows an URL to confidential data. In addition, the 
invention provides security without requiring the installation of new client or target server 

10 software. Other features and advantages of the invention, and embodiments of the 
invention in methods, storage media, and signals, will all become more fully apparent 
through the following description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

15 To illustrate the manner in which the advantages and features of the invention are 

obtained, a more particular description of the invention will be given with reference to the 
attached drawings. These drawings only illustrate selected aspects of the invention and 
thus do not limit the invention's scope. In the drawings: 

Figure 1 is a diagram illustrating a secure network, a client outside the network, 
20 and several aspects of the present invention which allow secure communication between 
the client and the network. 

Figure 2 is a flowchart illustrating several methods of the present invention. 
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Figure 3 is a diagram further illustrating one embodiment of the client and secure 
network shown in Figure 1 . 

Figure 4 is a diagram further illustrating another embodiment of the client and 
secure network shown in Figure 1 . 

5 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention relates to methods, systems, signals, and devices for 
providing a user located outside a secure network with convenient, efficient, and secure 
access to data stored within the network. In particular, the invention provides and uses 
10 novel modifications to uniform resource locators (sometimes called "universal resource 
locators" or iC URLs") to protect user authentication information and to protect data such 
as intranet Web pages which are sent to the user from within the secure network. Various 
components of the invention and its environment are discussed below. 

15 Network and Computer Architecture 

One of the many secure computer networks suited for use with the present 
invention is indicated at 100 in Figure 1. The secure network 100 has a security perimeter 
102 which is defined by firewall software, routing limitations, encryption and/or other 
means familiar to those of skill in the art. Authorized users can log into particular servers 
20 and/or to the network as a whole from clients within the security perimeter and access 

data of the network 100 subject only to permissions, database locks, and the like, whereas 
attempts by the same authorized users to access the same data from outside the perimeter 
102 are generally not allowed (at least, not without the invention or similar functionality). 
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A wide variety of secure networks 100 may be configured according to the 
invention, including both individual computer networks and larger networks which are 
aggregations of smaller networks. For example, suitable computer networks 100 include 
local area networks, wide area networks, and/or portions of the Internet such as a private 
5 Internet, a secure Internet, a value-added network, or a virtual private network. The 
secure network 100 may also include or consist of a secure intranet, which is a secure 
network that employs TCP/IP and/or HTTP protocols internally. 

In one embodiment, the secure network 100 includes Novell NetWare*® network 
operating system software (NETWARE is a registered trademark of Novell, Inc.). In 
10 alternative embodiments, the secure network 100 includes NetWare Connect Services, 
VINES, Windows NT, Windows 95, Windows 98, Windows 2000, LAN Manager, or 
LANtastic network operating system software and/or an implementation of a distributed 
hierarchical partitioned object database according to the X.500 protocol such as Novell 
Directory Services or Lightweight Directory Access Protocol (LDAP) directory services 
15 (VINES is a trademark of Banyan Systems; NT, WINDOWS 95, WINDOWS 2000, and 
LAN MANAGER are trademarks of Microsoft Corporation; LANTASTIC is a trademark 
of Artisoft). The secure network 100 may be connectable to other networks, including 
other LANs or portions of the Internet or an intranet, through a gateway or similar 
mechanism. 

20 The secure network 100 includes one or more file or object or Web servers such as 

a target server 104. The secure network 100 also includes at least one border server 106. 
The target server 104 and the border server 106 will often run on separate machines, but 
they may be merely separate processes which share one machine. 
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In the illustrated configuration, the border server 106 includes an URL transformer 
108 and one or more caches 1 10. As discussed in greater detail below, the URL trans- 
former 108 modifies uniform resource locators (URLs) to protect the confidentiality of 
data sent to a user outside the secure network 100. The caches 1 10 are also discussed 
5 below. 

The secure network 100 may include additional servers and zero or more internal 
clients. The servers and the internal clients (if any) within the secure network 100 are 
connected by network signal lines to permit communications links between them in the 
form of network connections. In addition to their functionality as described herein, one or 
10 more of the servers 104, 106 may also be configured by those of skill in the art in a wide 
variety of ways to operate as Internet servers, as intranet servers, as proxy servers, as 
directory service providers or name servers, as software component or other object 
servers, or as a combination thereof A given computer may function both as an internal 
client and as a server; this may occur, for instance, in peer-to-peer networks or on 
15 computers running Microsoft Windows NT or Windows 2000 software. The servers 104, 
106 may be uniprocessor or multiprocessor machines. The servers 104, 106 and internal 
clients (if any) each include an addressable storage medium such as random access 
memory and/or a nonvolatile storage medium such as a magnetic or optical disk. 
Suitable network 100 internal clients include, without limitation, personal 
20 computers, laptops, workstations, disconnectable mobile computers, mainframes, 

information appliances, personal digital assistants, and other handheld and/or embedded 
processing systems. The signal lines which support communications links to the servers 
104, 106 may include twisted pair, coaxial, or optical fiber cables, telephone lines, 
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satellites, microwave relays, modulated AC power lines, and other data transmission 
a wires" known to those of skill in the art. Signals according to the invention may be 
embodied in such "wires" and/or in the addressable storage media (volatile and/or 
nonvolatile). In addition to the servers 104, 106 and any internal client computers, the 
5 secure network 100 may include other equipment such as printers, plotters, and/or disk 
arrays. Although particular individual and network computer systems and components are 
shown, those of skill in the art will appreciate that the present invention also works with a 
variety of other networks and computers. 

One or more of the servers 104, 106 and internal clients may be capable of using 
10 floppy drives, tape drives, optical drives or other means to read a storage medium. A 
suitable storage medium includes a magnetic, optical, or other computer-readable storage 
device having a specific physical substrate configuration. Suitable storage devices include 
floppy disks, hard disks, tape, CD-ROMs, PROMs, RAM and other computer system 
storage devices. The substrate configuration represents data and instructions which cause 
15 the computer system to operate in a specific and predefined manner as described herein. 
Thus, the medium tangibly embodies a program, functions, and/or instructions that are 
executable by the servers 104, 106 and/or clients to perform secure network access steps 
of the present invention substantially as described herein. 

The illustrated novel configurations also include an external client 1 12 which 
20 resides (at least initially) outside the security perimeter 102. The external client 1 12 may 
be a single workstation, for instance, or another machine of the types discussed above in 
reference to internal clients. Indeed, internal clients and external clients may differ merely 
in physical location and in the fact that internal clients have ready access to data stored on 
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the target server 104 without the present invention while external clients gain access 
through the invention. The external client 1 12 may also be a server which provides secure 
access between the secure network 100 and one or more secondary clients 1 14 on a 
network 1 16 which is served by and/or accessed through the client 112. 

5 

Operation 

With continued reference to Figure 1 and with reference to Figure 2 as well, the 
invention operates generally in the following manner. During a requesting step 120, the 
external client 1 12 requests access to data which is stored on the target server 104. From 
10 the perspective of the target server 104, this involves receiving a request during a step 

200. 

By checking the TP address from which the request was made, communicating with 
the firewall software, or other familiar means, the target server 104 determines that the 
request came from outside the security parameter 102. Accordingly, the target server 104 

15 does not simply provide the requested data. Of course, even if the request came from 
inside the security parameter 102, the target server would generally check user 
permissions against access control lists associated with the data, or take other steps to 
make sure the requesting user is entitled to access the requested data before providing that 
data. User permissions, access control lists, labels, and similar security controls which 

20 have a granularity smaller than the security perimeter 102 may continue to be used in 
combination with the security constraints described herein. 

In one embodiment, a redirector on the border server 106 redirects the -request 
from the client 1 12 to the border server 106 during a step 122. The border server 106 is 
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advertised as the target server 104. In practice, the border server 106 will often be on a 
separate machine than the target server 104, but those of skill in the art will appreciate that 
the target sen/er 104 and the border server 106 may also run on the same machine. The 
redirection may be accomplished using redirection capabilities which are part of the HTTP 
5 protocol. These redirection capabilities are conventionally used to automatically redirect 
Web browsers when a Web site has moved, that is, when the URL for the Web site has 
changed. In the context of the present convention, the Web site for which access is sought 
has not moved, in that the desired data still resides on the target server 104. Instead, 
HTTP redirection provides a convenient and efficient tool for sending requests from 
10 external clients to the border server 106 to maintain security as described herein. 

For example, assume that the target server 104 is identified by the URL 
"http://www. Novell. com". The redirection step 122 might return the following URL to 
the external client 112: 

http s : //B o rderManager: 443 9ti http ://www.No veil . com" 
15 (for authentication), or it might return the URL: 

https://Borde^Manager:443? ct https://www.Novell.com:443 ,, 
(authentication and force through the SSL-izer). Several things are worth noting in such a 
redirection URL signal. 

First, the redirection signal seeks to change the protocol from HTTP to HTTPS. 
20 As those of skill in the art will recognize, the HTTPS protocol uses secure sockets layer 
communication. A familiar embodiment of secure sockets layer communication is provided 
by SSL software operating according to United States Patent No. 5,825,890 assigned to 
Netscape Communications Corporation. However, as used herein the term "secure sockets 



13 



layer communication' is not limited to SSL connections but instead includes any form of 
network communication which utilizes encryption in TCP/IP sockets and which is widely 
available in Web browsers and the servers with which those browsers communicate. 

Second, the redirection signal refers to the border server 106 as "BorderManager" 
5 in deference to the BorderManager product line from Novell, Inc. (BorderManager is a 
mark of Novell, Inc.). Those of skill in the art will understand that the border server 106 
need not be a Novell BorderManager server, but need merely operate as claimed herein. 

Third, the redirection signal refers to port 443 of the border server 106. Those of 
skill in the art will appreciate that other ports may also be used, through a port override, 
10 for instance. Moreover, redirection need not utilize a dedicated port; it is simply conveni- 
ent in many cases to do so. 

Fourth, in its most general form, the redirection signal simply includes a delimited 
non-secure URL adjoined to a secure URL. The non-secure URL http://www.Novell.com 
identifies the target server 104, while the secure URL https://BorderManager identifies the 
15 border server 106. To conform with HTTP syntax, the non-secure URL is delimited in the 
example redirection signal by double quotes, other delimiters may be used with other 
protocols. The non-secure URL is non-secure because it does not require use of a secure 
connection such as a secure sockets layer or SSL link; the secure URL is secure because it 
does require such a secure connection. 
20 Fifth, those of skill in the art will appreciate that directory path names and 

filenames may be appended to these examples to identify specific Web pages or other 
protected resources. For instance, the original request may have been for the web page 
which is located at u http://www.Novell.com/~hashem/foo_design.htm". 
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Sixth, those of skill in the art will also appreciate that FTP files, gopher resources, 
and other data on the target server 104 may be handled in a similar manner. 

Finally, those of skill in the art will appreciate that a wide variety of signal field 
orderings, data sizes, and data encodings, and other variations are possible. The inventive 
5 signals may also be embodied in a system in various media. For instance, they may take 
the form of data stored on a disk or in RAM memory, or the form of signals on network 
communication lines. Some embodiments will include all signal elements discussed above, 
while others omit and/or supplement those elements. However, the distinctive features of 
the invention, as set forth in the appended claims, will be apparent in each embodiment to 
10 those of skill in the art. 

During a step 124, a secure connection is formed between the border server 106 
and the external client 112. This connection may be, for instance, an SSL connection 
formed in response to use of "https" as a protocol indicator in a request from the client 
1 12 to the border server 106. For convenience, reference is made primarily to connections 
15 with a user of the external client 1 12. However, as noted earlier the client 1 12 may itself 
be a server or another node in a communications path between a user who is located at 
another machine 1 14 and who is seeking access to target server 104 data. 

As indicated in Figure 2, in some cases the external client 1 12 may contact the 
border server 106 directly so that no redirection is needed. That is, the initial request for 
20 access to the target server 104 may be directed to the border server 106 to save time. 
Moreover, the initial request may be combined with a request for a secure connection as 
discussed with reference to step 124. 
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Alternatively, the secure connection may be formed during step 124 before a 
specific request is made to the target server 104 despite the fact that step 200 is shown 
above step 124 in Figure 2. More generally, steps according to the present invention may 
be performed in a variety of orders and the execution of steps may overlap when the result 
5 of one step is not required by another step. Steps may also be omitted, renamed, repeated, 
or grouped differently than shown, provided they accomplish the claimed process. 

During a step 126, the user is authenticated to the secure network 100. This 
generally involves transmitting user authentication information over the secure connection 
from the client 1 12 to the border server 106, verifying the information within the secure 
10 network 100, and notifying the user that the authentication information has been accepted 
as valid. This may be accomplished in various ways. 

For instance, some embodiments use an HTML page with scripts, or a Java applet, 
to present the user with a login screen. The user enters a user name and a corresponding 
password in fields shown on the login screen. The username and password are then 
15 transmitted over the secure connection to the border server 106, which passes them in turn 
to an authentication system within the secure network 100. If the username and password 
are validated by the authentication system, the border server 106 so notifies the user, and 
the user is then granted access to secure network 100 data as described herein (subject to 
permissions and the like). 
20 In one embodiment which utilizes Novell NDS software 140, the username and 

user password presented by the user are that user's regular NDS name and password, 
which the user would typically present when logging into the secure network 100 from an 
internal client. The user need not manage a separate username and/or password in order 
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to login from an external client. The login screen presented to the user may also include 
contextual information, such as the user's context within an NDS tree. The border server 
106 presents the NDS username and password to the familiar NDS user authentication 
system, and looks to that authentication system for rejection or validation of the authenti- 

5 cation information. Instead of using a Novell Directory Services database 140, or in 
addition to that database, the user authentication system may include a Microsoft 
Windows NT Domain directory 140. An embodiment of the invention which does not 
utilize NDS software may also authenticate a user to all servers in the secure network 100 
after recognizing a single user name and a single corresponding user password. 

10 During a step 128, non-secure data 130 is transmitted from the target server 104 

to the border server 106, where it will be modified to promote continued security and then 
forwarded to the external client 1 12 during a transmitting step 132. In one embodiment, 
the transmitting step 128 includes a preliminary act and one or more subsequent repeated 
acts, as follows. 

15 The preliminary act within the transmitting step 128 is to direct (or redirect) the 

external client 1 12 to the target server 104, and to promote use of a secure connection in 
so doing by making a secure connection the default. This may be done by using the HTTP 
redirection capability in combination with substitution of "https" for "http" in the URL 
which identifies the target server 104 data sought by the external client 112. In the 

20 example above, the original request from the external client 1 12 was for data at 

"http://www.Novell.com" so the redirection back to the target server 104 (after the user is 
authenticated to the secure network 100 during step 126) would seek data at 
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"https://www.Novell.com" with directory and path names appended as in the original 
request. 

The possibly repeated acts within the transmitting step 128 involve sending one or 
more Web pages, files, or other pieces of non- secure data 130 from the target server 104 
5 to the border server 106. The data 130 is non-secure in that it includes hypertext links, 
URLs, or other references which, if presented by the external client 1 12 to the secure 
network 100, would not necessarily require use of a secure connection such as an SSL 
connection and which might allow non-secure access to protected network 100 data. For 
instance, Web pages which contain URLs specifying "http://" rather than "https://" in 
10 reference to data stored on the target server 104 are examples of non-secure data 130. 

During an optional caching step 202, the non-secure data 130 may be cached in a 
cache 1 10 at the border server 106. Caching tools and techniques familiar in the art may 
be used; caching is discussed further below. 

During a transforming step 204, the non-secure data 130 is transformed into 
15 secure data 134 by an URL transformer 108 which replaces non-secure URLs with 

corresponding secure URLs. For instance, the URL transformer 108 may employ familiar 
string search-and-replace algorithms to replace each instance of the string "http" which is 
tagged in HTML data 130 as an URL protocol indicator by the string "https". As noted, 
similar steps may be taken with FTP and other protocol indicators. 
20 Care should be taken to avoid replacing string instances which are not being used 

within an URL as a protocol indicator. For example, instances of the string "http" in the 
text of this patent application would not be replaced, nor would instances which are being 
used as part of a directory path or a filename rather than a protocol indicator, because 
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such replacements would not promote continued use of secure sockets layer 
communication. 

Like other elements of the present invention, the transformer 108 may be 
implemented using the teachings presented here with programming languages and tools 
5 such as Java, Pascal, C++, C, Perl, shell scripts, assembly, firmware, microcode, logic 
arrays, PALs, ASICs, PROMS, and/or other languages, circuits, or tools as deemed 
appropriate by those of skill in the art. 

During an optional caching step 206, the secure data 134 may be cached, using 
caching tools and techniques familiar in the art. Either, both, or neither of the caching 
10 steps 202, 206 may be present in a given embodiment. That is, the border server 106 may 
include zero, one, or two caches 1 10. 

For instance, the non-secure data 130 may be stored in one cache 1 10 while the 
secure data 134 is stored in another cache 110. Secure data 134 is transmitted during a 
step 132 to external clients 112 from the secure cache 110, while non-secure data 130 is 
15 provided to internal clients from the non-secure cache 1 10. This split cache configuration 
provides the benefits of caching both to external clients and to internal clients, and it does 
not impose URL transformation processing costs on internal clients that only access non- 
secure data 130. 

Another configuration stores data requested by external clients in one cache 1 10 
20 regardless of whether the data has also been requested by internal clients, and stores data 
requested only by internal clients in another cache 1 10. The data requested by external 
clients is stored in its non-secure form and its URLs are transformed to create secure data 
134 only as needed before putting data on the wire to an external client. The data sent to 
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internal clients may include a mixture of non-secure data 130 and secure data 134; during 
step 132 only secure data 134 is sent to external clients. 

Alternatively, all data sent to internal and/or external clients may be stored in a 
single cache 1 10, with URL transformation again being performed on-the-fly as needed 
5 when cached data is to be sent to an external client during step 132. Of course, caching 
may also be simply omitted in some embodiments. 

As discussed above, the invention may operate by sending non-secure data 130 
from the target server 104 to the border server 106, where the data is transformed by the 
URL transformer 108 and then transmitted as secure data 134 to the external client 1 12. 
10 Several variations on this approach are also possible according to the invention. Some 
involve caching alternative discussed above. Other variations alter the location or function 
of the URL transformer 108 and/or involve tunneling. 

For example, after the user is authenticated during step 126 the border server 106 
may function merely as a node on a path which carries secure data 134 from the target 
15 server 104 to the external client 112. This configuration may be appropriate if the target 
server 104 only holds secure data 134. Even if the URL transformer 108 rarely or never 
modifies any URLs in practice, it may still be capable of performing such modifications in 
case its filtering function does find any non-secure URLs. In addition, or as an alternative, 
the URL transformer 108 may notify an administrator if non-secure URLs are found. 
20 It may also be appropriate for the border server 106 to function merely as a data 

carrier node if an URL transformer 108 is part of the target server 104 instead of (or in 
addition to) being part of the border server 106. The target server 104 can then transform 
any non-secure data 130 into secure data 134 before forwarding that data 134 to the 
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border server 106 for subsequent transmission to the external client 1 12. For example, in 
one embodiment a transmitting step 136 sends secure data in tunneling packets 138 to the 
border server 106, which then forwards the data 138 to the external client 1 12 during a 
step 132. Familiar tunneling tools and techniques may be used during step 136 to transmit 
5 data which has been made secure through URL transformation according to the invention. 

Additional Information 

Figures 3 and 4 further illustrate the invention. Figure 3 shows a configuration 
containing two target servers 300, 302, illustrating the fact that some embodiments of the 
10 invention involve two (or more) target servers 104. Thus, confidential data 304 to which 
an external client 1 12 seeks access may be stored in the secure network 100 on one or 
more target servers 104. The protected data 304 may be a mix of secure (e.g., containing 
"https" only) data and non-secure (e.g. at least one instance of "http" referring to data 
within the secure network 100) data. 
15 In Figure 3 the URL transformer 108 is located in the border server 106. By 

contrast, Figure 4 shows a configuration in which the URL transformer 108 is part of the 
target server 104. Accordingly, the configuration of Figure 3 assumes that non-secure 
confidential data 304 is sent from the target server 104 to the border server 106, trans- 
formed at the border server 106 by the URL transformer 108, and then provided to the 
20 external client 112. By contrast, the configuration of Figure 4 assumes that non- secure 
confidential data 304 is transformed into secure data by the URL transformer 108 at the 
target server 104, after which the modified data is sent either directly to the external client 
1 12 (bypassing the border server 106) or indirectly to that client 1 12 by way of the border 
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server 106. Indirect transmission of secure data from the target server 104 through the 
border server 106 to the external client 1 12 could utilize, for instance, familiar tunneling 
tools and techniques. 

For purposes of illustration, Figure 3 shows both a non-secure data cache 306 and 
5 a secure data cache 308 as part of the border server 106. As discussed above, however, 
the border server 106 may also be configured according to the invention with only one of 
these two caches 306, 308, or with a combined cache 1 10 containing both secure and non- 
secure data, or with no cache 1 10. Those of skill in the art will also appreciate that the 
target server 104 may also include zero or more caches 110. 
10 The border server 106 includes secure sockets layer software 310, and the external 

client 1 12 includes corresponding secure sockets layer software 318. As noted above, any 
commercially available software which provides a secure connection through encryption at 
the sockets level can be used to form the secure connection provided by the software 3 10, 
318. Suitable software 3 10, 318 thus includes the SSL software provided commercially 
15 by Netscape Corporation and other vendors. 

The border server 106 also includes management software 312. In various 
embodiments, the management software 312 provides some or all of the following 
functionality to permit system operation as discussed herein: handling requests which are 
redirected during step 122 and subsequently redirecting the external user back to that 
20 target server 104 after step 124 forms a secure connection and step 126 authenticates the 
user; invoking the URL transformer 108 as necessary to prevent non-secure data from 
being transmitted to an external client 1 12; managing the caches 110; interfacing with a 
network user authentication system 3 16 such as the NDS authentication system, logging 
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user and/or system activity; alerting administrators to possible problems such as multiple 
failed authentication attempts, failed secure connection attempts and/or lack of resources 
such as memory or disk space; and managing information such as the IP address and/or 
session identifier used by a given external client 1 12 to make certain that secure data is 

5 transmitted only to the authenticated user. 

The border server 106 also includes standard network and operating system 
software 314. Suitable networking software 314 includes Novell NetWare software, 
various TCP/IP implementations, Ethernet software, and other commercially available 
networking software. Suitable operating system software 3 14 includes UNIX, Linux, and 

10 UNIX variations, Microsoft Windows, and other commercially available operating system 
software. 

The client 1 12 likewise includes networking and operating system software 320. 
Suitable software 320 includes commercially available software such as that previously 
mentioned. It is not necessary for the client 1 12 and the border server 106 to be running 
15 the same operating system and/or the same networking software, so long as a secure 

connection can be formed. For instance, the border server 106 might use UNIX software 
while the client 1 12 runs Windows 2000 software, with each using their respective SSL 
software to provide the necessary secure connection. 

The client 1 12 includes an application program or some other piece of requesting 
20 software 322 which makes the access request during step 120. Requests may be 

prompted by human users and/or by system tasks or threads. The software 322 which 
seeks access to confidential data 304 from outside the security perimeter 102 will often be 
a Web browser. However, the present invention also provides secure access to other 
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types of requesting software, including without limitation: indexing programs, search 
programs, database-building tools, archival tools, administrative tools, collaborative 
writing tools, multimedia conferencing software, and lower-level software such as file 
system software, operating system software, and/or networking software. 
5 The client 1 12 also contains user authentication information 324. As noted above, 

the authentication information 324 which is used to authenticate the user and/or client to 
the network 100 during step 126 will often include a user name and a corresponding user 
password. These are preferably the same name and password used by the authorized user 
to log into an internal client of the secure network 100. In place of, or in addition to a 
10 user name and password, the authentication information may include certificates, tokens, 
public keys, and/or data from authentication tools such as biometric scans, voice prints, 
retinal scans, fingerprint scans, magnetic card reader results, and so on. A wide variety of 
suitable authentication information is familiar to those of skill in the art. 

The configuration shown in Figure 4 has much in common with the configuration 
15 shown in Figure 3, at least with respect to many of the individual components. For 

instance, the comments made above regarding the confidential data 304, the caches 1 10, 
the URL transformer 108, the secure sockets layer software 3 10, 3 18, the network and 
operating system software 3 14, 320, the requesting software 322, the network user 
authentication system 316, and the user authentication information 324 apply to both 
20 Figures. 

However, the functionality of the management software 312 on the border server 
106 may be divided in the configuration of Figure 4 between management and tunneling 
software 400 in the target server 104 and management and tunneling software 402 in the 
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border server 106. The management software 312 functionality may also be supplemented 
by tunneling functionality. Suitable tunneling functionality is available through the 
literature and commercially available tunneling implementations. 

The software 400 may also include the redirector for redirecting to the border 
5 server 106 the request made by the client 1 12 for direct access to the target server 104. 
This allows user authentication during step 126 to be performed by the border server 106 
while URL transformation and data transmission are performed by the target server 104 
and/or by the target server 104 in combination with the border server 106. 

10 Summary 

The present invention uses novel URL transformations and/or more familiar 
mechanisms such as HTTP redirection and SSL software to provide secure authentication 
of a user from an external client and to then provide secure transmission of confidential 
data between the target server and the external client. By transforming non-secure URLs 
15 into secure URLs, the invention forces continued use of secure communications despite 
the inherent security problems of HTTP. These problems arise from the fact that HTTP 
does not normally "remember" security requirements from one Web page transmission to 
the next. The present invention forces use of a secure connection each time the user 
follows an URL to confidential data. Moreover, the invention provides this security 
20 without requiring any additional distribution or installation of client software onto the 
external client(s) beyond that which is already widely used. 

Although particular methods and signal formats embodying the present invention 
are expressly described herein, it will be appreciated that system and storage media 
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embodiments may also be formed according to the signals and methods of the present 
invention. Unless otherwise expressly indicted, the description herein of methods and 
signals of the present invention therefore extends to corresponding systems and storage 
media, and the description of systems and storage media of the present invention extends 

5 likewise to corresponding methods and signals. 

As used herein, terms such as "a" and "the" and item designations such as "URL" 
are inclusive of one or more of the indicated item. In particular, in the claims a reference 
to an item means at least one such item is required. When' exactly one item is intended, 
this document will state that requirement expressly. 

10 The invention may be embodied in other specific forms without departing from its 

essential characteristics. The described embodiments are to be considered in all respects 
only as illustrative and not restrictive. Headings are for convenience only. The scope of the 
invention is, therefore, indicated by the appended claims rather than by the foregoing 
description. All changes which come within the meaning and range of equivalency of the 

15 claims are to be embraced within their scope. 

What is claimed and desired to be secured by patent is: 
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